PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.15

Text File | 1988-04-08 | 31.1 KB | 829 lines | [TEXT/ttxt]

 1-Feb-88 10:39:30-PST,32623;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 1 Feb 88 10:37:25 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad23226; 1 Feb 88 10:49 EST
Received: from relay.cs.net by RELAY.CS.NET id aa24770; 1 Feb 88 10:34 EST
Received: from sdr.slb.com by RELAY.CS.NET id ae24701; 1 Feb 88 10:30 EST
Date: Mon, 1 Feb 88 09:37 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #15
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 1 Feb 88 09:36:57-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #15
To: Usenet-List: ;
Message-ID: <570706617.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Sunday, January 31, 1988       Volume 4 : Issue 15

Today's Topics:
     Re: PostScript Programming
     Lex for The Mac??
     Re: Big Disks
     Re: Looking for Mr. GoodDraw
     Re: MS Excel versions
     Re: MultiFinder/Finder 6.0 difficulties
     Re: LSC prototypes question
     Re: (LSC) Deep Dark Secrets Wanted!
     4th Dimension not *that* good (?)
     Re: Looking for Mr. GoodDraw
     National Semiconductor 16M card and A/UX
     Setting cursor position and mouse speed.
     Re: SAS/GRAPH on Mac
     Shareware Curiousity
     Re: SAS/GRAPH on Mac
     LSC DrawString() question!  Help!
     Re: Anyone doing GPIB on MACII using National card?
     VLSI design tools
     Re: Anyone doing GPIB on MACII using National card?
     AU/X gudelines for Mac application development
     Yacc for the Mac!!!!
     Re: Setting cursor position and mouse speed.

----------------------------------------------------------------------

From: [e-mail] (David W. Berry)
Subject: Re: PostScript Programming
Date: 25 Jan 88 02:50:38 GMT
Organization: Apple Computer Inc., Cupertino, USA

    It also works by attaching a LaserWriter, downloading some stuff to it,
and running your program in the LaserWriter.  Preview is by uploading
bits from the LaserWriter to the mac.  It's a little slow but not
painful.  The debugging stuff looks real neat though.
>
>This information is provided for informational purposes only.  This is
>not an official Apple endorsement or review.
    Ditto.
--
    David W. Berry
    [e-mail]                   dwb@Delphi
    [e-mail]                   [e-mail]
Disclaimer: Apple doesn't even know I have an opinion and certainly
    wouldn't want if they did.


------------------------------

From: [e-mail] (Nathan Banks)
Subject: Lex for The Mac??
Date: 25 Jan 88 01:20:23 GMT
Organization: The Unix(R) Connection BBS, Dallas, Tx

Does anyone know where I might get lex for the Macintosh? Preferably
sources!  I downloaded the DECUS lex and am having problems porting it.
If someone else has done this it sure would save me the time.  I have
heard of a tool called MacYacc could there also be a MacLex???
--
Nathan Banks
UUCP: [e-mail]
USPS: 2701-C West 15th Street     BELL: [phone]
      Suite 411 Plano, Texas            [phone]
      75075-7523


------------------------------

From: [e-mail]
Subject: Re: Big Disks
Date: 25 Jan 88 01:11:00 GMT


I sure hope they go with 3.2Mb disks, even though the cost will probably
be much higher.  I feel this way because:

(a) it has always been ridiculous to sell machines with a main memory
larger than the main disks.  In the near future, multifinder will make
2Mb machines "standard" -- which would make 1.6Mb disks ridiculous.

(b) Once again it will be comfortable to run a floppy-only machine with
no disk-swap polka.  This will make low-end macintoshes much more
competitive.

(c) The cost in software distribution is horrendous.  Many companies
today must distribute 2,3,4, or 5 disks with their product.  This costs
money because:
 (1) The floppies themselves cost money, so does the extra duplication.
 (2) developers have to hassle with packing everything tightly on the
disks.

Are you listening Apple?

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {[e-mail]}


------------------------------

From: [e-mail] (William R. Pearson)
Subject: Re: Looking for Mr. GoodDraw
Date: 25 Jan 88 14:55:48 GMT
Organization: University of Virginia, Charlottesville

>I got Canvas just a few days ago, and although I haven't had a lot
>of experience with it, I am so far very pleased with it. The only

    I have discovered that most of my problems with Cricket Graph and
MacDraw are due to bugs in Cricket Draw.  But I am considering a better
drawing program.

    Can anyone compare CANVAS (~$120 disc) with Cricket Draw (~$175 disc).
Cricket Draw seems to be able to do color, and is frequently reviewed
with the more expensive Adobe Illustrator.  But I would like to make
filled solid arcs (made of two arcs and two straight lines on the ends),
and I have read that Cricket Draw will not group arcs and lines.  Does
CANVAS?

    Any comparison would be helpful.
--
Bill Pearson
[e-mail]


------------------------------

From: [e-mail]
Subject: Re: MS Excel versions
Date: 23 Jan 88 18:05:06 GMT
Organization: The Portal System (TM)

MS Excel is at Version 1.06 or so I was told at MacWorld by a person in
the MS Booth. I was there to complain about the MultiFinder bugs with
1.04 with regard to large memory spaces. I have 8megs and Excel bombs
far to often as it uses more and more memory. I was told that by calling
1-206-882-8089 and asking Excel Product Support for the Excel 1.06 patch
I would be fixed... Go for it!

Bob LaserMan Murrow


------------------------------

From: [e-mail]
Subject: Re: MultiFinder/Finder 6.0 difficulties
Date: 23 Jan 88 20:33:39 GMT
Organization: The Portal System (TM)

Another Problem:  Has anyone been able to get MacServer (V2.3) to work
with system 4.2/6.0.  When I try to install it the only option I have is
to install it as a user.  The server radio button is dimmed.
Suggestions???

Thanks -Mike


------------------------------

From: [e-mail] (Richard Siegel)
Subject: Re: LSC prototypes question
Date: 25 Jan 88 16:05:58 GMT
Organization: Carnegie Mellon University

Since I'm not a C ace, bear with me here... :-)

Given

    void myfun(x, y)
    register int x, y;
    {

    }

The legal prototype is

    void myfun(int x; int y);

or its semantic equivalent. You can't use "register" in a prototype as
you  have, because storage classes can't be used in prototypes, as you
accurately  surmised.

Note that the actual function *can* use register vars as its arguments;
you  have done that correctly.

The "invalid storage class" message is described in an appendix at the
back of  the C user's guide, along with all of the other error messages.

        --Rich
--
===================================================================
Richard Siegel
THINK Technologies, QA Technician (on leave)
Carnegie-Mellon University, Confused Physics Major
Arpa: [e-mail]
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u
==================================================================


------------------------------

From: [e-mail] (Gabriel Lawrence)
Subject: Re: (LSC) Deep Dark Secrets Wanted!
Date: 25 Jan 88 17:39:32 GMT
Organization: Bolt, Baranek and Newman Inc., Cambridge MA

Of course the easiest way to make a DA live forever is to use the same
"trick" that MultiFinder uses, place the DA into the System heap rather
than the application heap.  There are no restrictions I know of that
prevent a DA from placing a copy of itself into the System heap and
altering the DCE information to indicate the new location of the DA.
For non-critical timing background operation, setting the DA dNeedTime
header bit should suffice, relieving you from having to play games with
the Vertical Blanking Interrupt Manager.  I haven't written any DA's
that actually use this technique but it seems to work just fine for the
other types of device drivers I've written. Does anybody detect any
logical flaws to this approach?
--
=Gabe Lawrence=
=BBN Communications=

USENET: ...!harvard!bbn![e-mail]
INTERNET: [e-mail]


------------------------------

From: [e-mail] (henq)
Subject: 4th Dimension not *that* good (?)
Date: 24 Jan 88 21:48:15 GMT

Recently, someone invited remarks on the various DBMS we have for the
Mac.

(I lost his address, thats why I post instead of mailing, sorry)

Though I personnally have only played a little with 4th, some people I
know have tested the product to a larger extent. The message is they are
dissappointed, after initially being pleased with the Maccish like  user
interface.

The complaints are(the ones I remember):

1. It is not possible to switch entry-lay outs with a single custom
button- press. A menu-selection is always involved.

2. Buttons are not displayed in 'browse' mode, only in modify or insert
mode. This makes it impossible to browse through a file with
custom-buttons.

3. sometimes the screen gets not updated, for example after an 'Next
Record'  instruction after a find.

4. The way the scrolling fields  get drawn is ugly, arrows and thumbs
are not clipped on their windows boundaries.

5. The rumoured lack of speed indeed is a problem. A friend of mine has
made a management information system of about 20 related files,
containing customers, stock, repairs, invoices, etc.  When a customer
calls, he is found by typing his code or his number, or by  browsing. If
he wants to know the status on his mac-to-be-repaired, a button- click
switches to the Repairs file, selecting the most recent repair order of
that customer. All this works very well and very fast. It is written in
Omnis3 :-(.                     ^^^^^  (between the bombs, that is)

This friend has tried to make an equivalent system in 4Th dim.
According to him, 4Th dim currently has too many limitations to build an
equivalent system. One limitation being the lack of speed.

I hope someone can prove him wrong.

6. A complained from myself , after having toyed with it.  The  user
interface is _rude_.

6a The grid in the entry-lay out is useless. Ever tried to make nice
border- boxes around fields ? A  pain. 6b When selecting multiple fields
(using a marquee), also the gray rect and the black drop-shadow rects
get selected, and it is very difficult to shift-unselect them.

...and numerous other little but annoying user-interface quircks.

7 The whole program is very modal. If you choose one mode(Environment),
all windows of the other environment get closed. If you get back at  the
previous mode, and open the same windows, they have forgotton their
settings (location, size, fontsize,..).

Acius should look at Filemaker plus and get inspired by the user
interface of that product. I think it would also be good for the u.i. of
4Th dimension if it where ported to MacApp. (For example, the
'Structure' window would become WYSIWYG, and get 'Show paper borders'
lines).

8 There is no easy way (that is, whitout making procedures) to make a
selection of a file using as criterium a field of a linked file.

I mean the kind of selection SQL (and dBAseMac ?) allows:

'Give all customers that have a Mac in repair with a repair cost of over
$100.' (The repair data is kept in a file seperate from the customers.)



I hope the most of the above points stem from the fact I and my friends
do not understand the product very good. In that case I apologize.  If
4Th dim indeed suffers formentioned shortcommings (and perheps even
others), I hope they will get addressed in future releases. Because, I
like the  product (really!), but in its current implementation I do not
dare to advice it to others, because I fear that when they try to build
a realy complex sytem, it will reach its limits much sooner that Omnis3
will.

-Henk van Tijen

Have a nice day


------------------------------

From: [e-mail] (William H. Jefferys)
Subject: Re: Looking for Mr. GoodDraw
Date: 25 Jan 88 17:59:02 GMT
Organization: UT AUSTIN Astronomy Department/McDonald Observatory

I can't compare them as I have never used Cricket Draw, but the
following may be helpful. Canvas does support the 8 basic colors. As for
the question about arcs, it won't do it exactly as you mention, but you
can get the same effect (as I found experimentally) as follows:

Create an arc, and fill it with some pattern (that will give you a
pie-shaped wedge). Duplicate it and shrink the second arc to the desired
smaller radius. Then put the points of the pie wedges on top of each
other. Now comes the trick: Select both wedges, and set them so that
they COPY in XOR mode. The overlapping pieces of pie will cancel each
other, leaving a filled piece of an annulus, which is (I think) what you
want. If you group the two objects and move it on top of another, the
other object will show through! So it's just like having a filled
annulus and nothing else.

Bill Jefferys

--
Glend.    I can call spirits from the vasty deep.
Hot.    Why, so can I, or so can any man; But will they come when you
    do call for them?    --  Henry IV Pt. I, III, i, 53


------------------------------

From: [e-mail] (Yossie Silverman )
Subject: National Semiconductor 16M card and A/UX
Date: 25 Jan 88 21:23:48 GMT
Organization: National Semiconductor (Israel) Ltd.

Does anyone know if A/UX can take advantage of offboard memory like
National Semiconductors 16M cards?  I know, I work for them but I can't
seem to find out through internal sources so I am asking the network.
--
Yossie Silverman                                   What did the Caspian sea?
National Semiconductor Ltd. (Israel)                - Saki
UUCP: taux01![e-mail]
NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOCLAY ITAY


------------------------------

From: [e-mail] (Robert Dorsett)
Subject: Setting cursor position and mouse speed.
Date: 25 Jan 88 21:19:18 GMT
Organization: Austin UNIX Users Group, Austin, Tx.

A few weeks ago, I posted a request for tips on how to set the screen
cursor position, totally under software control, then reassociating that
position with the mouse.  Eric Eide ([e-mail])
kindly helped fill in some information that Apple, for some reason, has
chosen to leave out of all its documentation (without even providing a
ROM call to work around the lack of low-memory information).  Before I
start receiving flames: yes, I know it's a bad idea to screw around with
low memory, but one has no choice.


SO, here's a picture of relevant memory (courtesy Mr. Eide):

Variable MTemp, point (longword), $828.  You can get at it from
Lightspeed C by defining the variable

    extern point mtemp : 0x828;

somewhere in your program.  You can use the same syntax for all the
variables I discuss.  I'm not really sure what the variable does; it
seems like an inter- mediate counter to take care of non-sequential
movements.  There are quite a few data structures to handle cursor
position, so this may not be correct.

Variable RawMouse, point (longword), $82C.  This is apparently the raw,
input  mouse position before processing by the vertical retrace
interrupt manager (?).

Variable CrsrBusy, boolean (byte), $8CD.  Prevents the mouse handler
routines from doing anything to the cursor while we're messing around
with it.

I initially tried the sequence (given a point I wished to move to):
    crsrbusy=TRUE;
    mtemp=mypoint;
    rawmouse=mypoint;
    crsrbusy=FALSE;

which didn't work.  That basically simulates "ObscureCursor()", i.e.,
it'll hide the cursor until you move the mouse, then it'll jump to the
desired location on the screen.

Mr. Eide later pointed out that for total software control, using the
"temp- orary" variables", one needs another variable, CrsrNew.  This can
then be inserted right before the last crsrbusy assignment to inform the
system that the cursor needs updating.  The variable is located at $8CE,
and is a boolean (byte).  I have not tried this, though.

In the meantime, I searched for other ways, since I had to have absolute
soft- ware control of cursor position.  In a 1985 variable listing
(fortunately, I don't throw things away), I discovered variable Mouse, a
point (longword), at  location $830.  This is the "Mouse" position, such
as "GetMouse()" might  return.

I found that I was able to change the cursor position with simply
    mouse=mypoint;

but I still change the cursor busy state to be safe.  I haven't had a
crash since playing with this stuff.

Mild flame at Apple: most of the above is relatively undocumented.  It
is not in Inside Macintosh or any of the Tech Notes.  Mr. Eide got his
information  from a book by Scott Knaster.  I managed to fill in the
rest from the afore- mentioned variable list.  I can sympathize with the
rationale in not wanting  people to mess with cursor position, but to
HIDE the information indicates a  certain lack of trust in the judgement
of developers (whether professional or amateur).  The notion of not
relocating mouse position isn't particularly deep or difficult to
understand, and I'd wager that anyone who has experienced a  cursor jump
(such as during a disk access) can testify to the faint feeling of
disorientation it causes.  I doubt that you'd find anyone who will
change  cursor position haphazardly (I am only interested because, when
I call hide- cursor, I want the cursor to be where it disappeared when I
call showcursor  again).  Your omission cost me a lot of time tracking
this down.

Incidentally, the above variables seem to work on the SE, as well as the
Plus.  They probably work on older Mac's as well, but I haven't tried.


On to part two of this post.

The new Macs (Plus and beyond), as we all know, save several levels of
mouse scaling in Parameter RAM.  The location and nature of this scaling
is complete- ly undocumented in Inside Mac IV, and is disguised by a red
herring  from the documentation for the old ROM's (crsrthresh) that is
completely  unused by modern systems.

I have not been able to get scaling to work (and would appreciate any
help from people who know how).  All I've been able to determine is that
the spvolctl field (a variable byte at location $208) has been redefined
under the 128K  and 256K ROM's to now include the scaling threshhold
that is actually used.   Those of you with interest may wish to mark
page II-372 of Inside Mac to in- dicate that the bits 11-15 of the
VolClik field (spvolctl is the high-order byte of VolClik) are now used
for scaling.  Problem is, the Control Panel only  sets bits 11, 12, 13,
and 14.  I don't know if bit 15 is reserved, or whether  it's to
indicate a level of sensitivity over and above "maximum" (it might be a
good idea on very large screens).  At any rate, one can determine the
mouse sen- sitivity after clearing bits 8-10, the sound level.  My
problem: if I write in  new values, nothing happens.  The cursor
sensitivity goes to maximum.  Anyone  who has clues as to why this is
so, please contact me.

And a last flame at Apple: again, the tendency in "developer" support
over the last six months or so has been to assume we don't know what
we're doing.  I am well aware of the flames that the Mac is difficult to
program, but I don't feel that an undue proportion of resources should
be dedicated to cranking out tech notes noting the difference between
such elementary concepts as a handle and a point.  Instead, PLEASE try
to keep the information as useful and professional as possible.  If you
can't publish information, don't publish. It's not your responsibility
to *teach* people how to program, yet there were at least three tech
notes last year which attempted to do precisely that.
--
Robert Dorsett                  {allegra,ihnp4}!ut-sally!ut-emx!
                    walt.cc.utexas.edu!mentat
University of Texas at Austin    {allegra, ihnp4}!ut-sally!ut-emx!auscso!mentat


------------------------------

From: [e-mail] (Tom Cole)
Subject: Re: SAS/GRAPH on Mac
Date: 26 Jan 88 00:53:41 GMT
Organization: SAS Institute Inc.,Cary NC,25712

Well, one pretty easy technique (if you have a little time) is to use
the SAS/Graph metagraphics capability.  This is a "generic" device
driver that  outputs a text file that contains all the graphics
generated, instead of spooling out a picture.  The format of the
metagraphics file is documented in a SAS technical report.  I believe
you must make a metagraphics attribute file that describes the eventual
device - identify the size of the graphics area, color support,
"hardware" polygon fill, etc.  SAS then generates the appropriate
metacodes.

You then use VersaTerm, Kermit, or whatever to download the file to your
Mac. You can then write a simple program that reads the meta file and
does the appropriate PICT-type drawing.  Save the picture as a MacDraw
image, or whatever.

I have a sample program (and the associated SAS/Graph attribute file)
that does this very job.  Send me email or whatever if you want more
details, the software is free (the Mac software that is, SAS/Graph is
*not* free).
--
Tom Cole, E-3
VAX Host Development
PO Box 8000
1 SAS Circle
Cary NC 27512

[The usual deal about opinions and employers, both of which I currently
 have and hope to keep...]
j


------------------------------

From: [e-mail] (Peter Merchant)
Subject: Shareware Curiousity
Date: 25 Jan 88 04:25:49 GMT
Organization: U.S. Merchant Marine Academy, Kings Point, NY

Recently, a batch of us were sitting around discussing the legality of
shareware, after reading some postings on the net, and some interesting
questions were brought up:

a) At many collegiate institutions, you buy your personal computer and
you agree that you will not be using it for business purposes.  So, if I
bought my Macintosh through the campus computer store, then I bought
Lightspeed Pascal (or C or whatever) and I wrote this neat program, is
it legal for me to charge money for it?

b) At many collegiate institutions, you have "public" Macintoshes (ie, a
room of Macs set up for people to use.)  If I were to buy a programming
language and write the same neat program that I wrote above, is it legal
for me to charge money for it?  Is the college, who owns the machine
that I did the work on, legally entitled to some percentage of the money
that I make?

c) I have a Macintosh sitting on my desk that is owned by my employer.
I write that neat program and charge money for it and I get a
significant amount of money for it, is my employer entitled to some
percentage of that money because I used their machine for the
development, even if the program was not developed on the employers
time?  The employer did, after all, provide the machine, the electricity
to run the machine, the heat for the office that the machine is in,
etcetera, etcetera... -- "You might as well jump..."           Peter
Merchant ([e-mail])


------------------------------

From: [e-mail] (Teriann Wakeman)
Subject: Re: SAS/GRAPH on Mac
Date: 25 Jan 88 23:30:56 GMT
Organization: HP Corporate Engineering - Palo Alto, CA

You didn't state if the graph was in bitmap or vector format. Bitmaped
drawings plot poorly. The plotter makes the drawing byproducing a number
of dots. If the drawing is enlarged, the plotter would draw it by
producing a series of blocks. If it is in vector format, it probably has
an option to save in PICT format. Once in PICT format it could be
plotted by a plotter driver. The current best on the market, in my
opinion, is  MacPlotts II (not to be confused with MacPlot) by Computer
Shoppe. Sorry, but I don't think it would help to bring a bit maped
picture into MacDraw then save it in PICT format. I think that it will
still look bit mapped.

Good Luck,

TeriAnn


------------------------------

From: [e-mail] (Ted Johnson)
Subject: LSC DrawString() question!  Help!
Date: 25 Jan 88 07:14:32 GMT
Organization: HP Design Tech Center - Santa Clara, CA

Could someone give me a hand with this strange LSC problem?  I am trying
to print a line of text in a DA's window, using code similiar to this:

    char tempstring[100];

        sprintf(tempstring, "%s %d %s %d","the square of",
            x, "is", (x * x));
        DrawString(CtoPstr(tempstring));
        PtoCstr(tempstring);

This works fine if I do it from a "regular" application (i.e., one which
prints all its results to LSC's stdio window), but it crashes with an ID
= 03 whenever I try to do it from inside a DA.  I am totally nonplussed.
 Can someone please give me a clue?  Thanks!

-Ted
--
-----------------------------
Ted Johnson
Hewlett-Packard
Design Technology Center
[phone]
UUCP: ...hplabs!hpdtc!tedj




------------------------------

From: [e-mail] (Richard Siegel)
Subject: Re: Anyone doing GPIB on MACII using National card?
Date: 26 Jan 88 15:36:15 GMT
Organization: Carnegie Mellon University


I believe that NI has interface libraries for (at least) LightspeedC.
Their  Mac software development (such as labVIEW) was done in
LightspeedC (smart  folks :-)). Give them a call; they're most helpful
in the technical  department, and may be able to get you started. I was
writing interfaces for  Lightspeed Pascal for their MacBus SCSI->IEEE
box, and they assisted  considerably.

        --Rich


------------------------------

From: [e-mail] (Markus Kaipainen)
Subject: VLSI design tools
Date: 25 Jan 88 14:56:11 GMT
Organization: Dep. of E. Eng., Linkoping University, S-581 83 Linkoping

Have anybody ported the VLSI design tools - Magic - to Mac II? Is there
someone out there planning to? Please let us know!

    Markus Kaipainen


------------------------------

From: [e-mail] (Paul Dietz)
Subject: Re: Anyone doing GPIB on MACII using National card?
Date: 26 Jan 88 17:54:52 GMT
Organization: Carnegie-Mellon University, CS/RI

I've been doing music synthesis on an NBMIO-16 analog I/O board, and
have had frequent opportunity to call National Instruments *toll free*
(very important for starving gradual students...) technical support
line. They try hard to be helpful, but not all the people who answer the
phones can answer the tough questions. When I'm lucky, I call when all
the support people are in a meeting, and I get to speak to one of their
engineers. That's when I really get answers to my questions.

The library routines are called 'LabDriver', and the early versions
still appear to be quite buggy. Whenever possible, I avoid their
libraries, and just use my own code.

--
Paul H. Dietz                                        ____          ____
Dept. of Electrical and Computer Engineering        / oo \        <_<\\\
Carnegie Mellon University                        /|  \/  |\        \\ \\
--------------------------------------------     | | (  ) | |       | ||\\
"If God had meant for penguins to fly,             -->--<--        / / |\\\  /
he would have given them wings."            _________^__^_________/ / / \\\\-


------------------------------

From: [e-mail] (Mahboud Zabetian)
Subject: AU/X gudelines for Mac application development
Date: 26 Jan 88 20:10:06 GMT
Organization: Advanced Technology, Princeton University


This is in response to the person who complained that Apple has not yet
released guidelines for mac applications that will run under AU/X.

The following is a summary of some of the responses that I received from
Apple. They may not be entirely correct, so please (anyone from Apple?)
correct me if I am wrong.


Most Mac binaries will not run under AU/X.  Less than 1% of current mac
programs follow guidelines sufficiently enough to run under AU/X.

Most applications run in a 24-bit address space and feel free to play
around with the high bits of the addresses.  AU/X uses the PMMU to
provide a 32-bit address space.

Applications cannot deal directly with hardware such as serial I/O chip
or  floppy controllers.

Toolbox packages NOT supported:

    Printing Manager
    Device Manager
    Disk Driver
    Sound Manager
    Serial Driver
    AppleTalk Manager
    Vertical Retrace Manager
    Disk Initialization Package
    SCSI Manager
    Time Manager



Well, that's as much as I know, please mail me any other info and I will
compil  a list.

--
Mahboud Zabetian                [e-mail]
183 Little Hall                     [phone]
Princeton University, Princeton, NJ 08544        [phone]
****** Anyone need a soon-to-graduate hardware/software engineer? ********


------------------------------

From: [e-mail]-rtl (Paul H Dunham)
Subject: Yacc for the Mac!!!!
Date: 26 Jan 88 20:37:48 GMT
Organization: Siemens Research and Technology Labs, Princeton NJ

I had heard that there are YACC's available for the Mac.  If so, where
do I get one?  Also how well will it work on my Mac II?

  Please respond by e-mail.

  Thanks,
    Paul H. Dunham
--
3608 Lancaster Ave| 105 College Rd East| [e-mail]
Phila, Pa. 19104  | Princeton, NJ 08540| [e-mail]
215/387-8723/home | 609/734-3611 (work)| rutgers!princeton!siemens!demon!dunham
*** Dante' drives a station wagon.  ***| cornell!rochester!udel!princeton...


------------------------------

From: [e-mail] (David Goldsmith)
Subject: Re: Setting cursor position and mouse speed.
Date: 26 Jan 88 18:26:30 GMT
Organization: Apple Computer Inc., Cupertino, USA

The reason that all of these globals and functions are undocumented is
that we consider them internal and not part of our published interface.
The list of low memory globals which was published in 1985 and again in
Scott Knaster's book are FOR DEBUGGING ONLY.  They do not constitute a
commitment by Apple to keep them in the same place or with the same
function.  The only globals whose use Apple supports are the ones
defined in Inside Macintosh and our Tech Note series.

I can't overemphasize how important this is.  We will not be able to
evolve our systems and software without breaking applications if
developers take advantage of unsupported and undocumented features.
Changing the mouse position directly is an operation we do not support.
The way this code works has changed already since the Macintosh was
introduced, as you yourself note in your posting, and may well change
again in future systems or software releases.  If it does, your
application will break.  We have already had trouble with applications
breaking because they assumed they could observe and/or modify low
memory globals which they knew of from the listings which have been
published.

I realize it can be frustrating to want to accomplish something and be
stopped because Apple does not give you a way to do it.  It's especially
tempting to work around this by snooping into the implementation of the
system and using the information gained.  This can only lead to problems
down the road.  Since everyone on this network is familiar with UNIX,
I'm sure you'll all agree that a system must have a defined architecture
which programmers adhere to if that system is to evolve.  It is
unfortunate that the Macintosh's runtime architecture does not make the
distinction between public and private globals apparent.

We are not perfect, and sometimes are not 100% clear on communicating
what should and should not be done, and what globals should and should
not be used.  Sometimes we even change our minds, since we are not able
to see into the future.  This is why we have a tech support department.

I hope this (rather long) posting helps to clarify the situation.

--
David Goldsmith
Apple Computer, Inc.

AppleLink: GOLDSMITH1
UUCP:  {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold
CSNET: [e-mail], dgold%apple@CSNET-RELAY
BIX: dgoldsmith

------------------------------

End of Usenet Mac Digest
************************
-------